내 데이터와 나만의 LLM: 환각을 몰아내는 데이터 파이프라인 (feat. sayou fabric)
저자: John Smith · 작성일: 2025-11-24 00:00:00 · 분야: Sayou Fabric
AI 패러다임: 내 것, 나만의 LLM
GPT를 시작으로 우리들의 일상에는 이제 LLM이 깊게 스며들었다. 여러분은 아직 아닌가? 그럼 설득을 해 드리도록 하겠다.
GPT 이외에도 쟁쟁한 LLM 네임드들이 많아졌다.
Google의 Gemini는 2.5 버전 시절도 좋았지만 3.0 버전이 출시되고 난 지금은 유래 없는 호평을 받고 있다.
위의 지난 게시글을 보면 알 수 있겠지만, 현대를 살아가는 우리들은 주식에 관심이 많다.
그런데 Gemini 3.0이 출시하고 난 뒤로 Google 주식이 마구마구 오르고 있다.
즉 LLM은 세계 경제를 움직였다. 그리고 움직이고 있다. 그것도 매우 크게.
만일 여러분이 LLM의 판도에 굳이 관심이 없다 하셔도, LLM이 세계 경제를 후려치고 있는 이상 그 영향력은 일상에 깊게 스며들었다 할 수 있겠다.
사실 LLM에 관심없는 분이 이 글을 읽고 계시진 않을 것 같지만.
그래서, 왜 이런 서두를 깔았느냐.
GPT가 터뜨리고 Gemini가 엎어친 흐름은 이제 알겠어. 하지만 어차피 그런 LLM들이 어떻게 발전하건 우리는 손도 못 대고 구경만 할 수밖에 없잖아.
그렇게 말씀하실 수 있다. 그리고 사실이다. 여러분이 Google에 입사해서 심부로 들어가지 않는 한 Gemini의 코어를 만질 수는 없을 것이다.
하지만, 반대로 생각해보자.
우리는 Gemini의 코어를 만질 수 없지만, Google도 우리 노트북의 파일을 만질 수는 없다.
내 노트북에 있는 이번 분기 회사 발표 자료들 요약해서 정리해 줘.
Gemini에게 이렇게 질문하면 한 마디로 내가 그걸 어떻게 알아. 라고 답변이 나온다.
Gemini가 가진 정보는 인터넷 등지에 산재한 공공의 정보들일 뿐, '내 것'은 Gemini가 알고 있을 리 없는 것이다.
여기서 포기할 것인가?
뭔지만 알면, 즉 데이터만 제공해 주면 그와 관련된 모든 질문에 만물박사처럼 답변을 돌려주는 LLM이 모니터 안에 있는데, 포기할 것인가?
아니면, 데이터를 제공해 줄 것인가?
여기서는 데이터를 한 번 제공해 주도록 하자. 그래야 이야기가 이어진다.
~25년 : 나는 무려 데이터를 제공했다
수집 [ Connector ] : 최초의 데이터
먼저, 제공할 데이터를 LLM에게 인식시켜야 한다.
위에서 언급된 예시대로라면, 회사 발표 자료들을 가져와서 직접적으로 제공해야만 한다.
내 노트북에 있어 저 폴더 안에 있어 라고 아무리 부르짖어도 LLM은 물음표만 띄울 테니까.
교수님한테 과제했는데 집에 있어요 진짜 열심히 했어요 A+ 주세요 라고 말하면 F 학점을 받는 것과 같다. 부디 가져다 드려야 하는 것이다.
그리고 이 데이터를 가져오는 작업은 수집, Connector 라고 불린다.
여기까지가, 우리가 25년도까지 해 온 대부분의 RAG 프로세스가 된다.
26년~ : 고통받는 LLM을 위하여
사실 위 단계에서도 나만의 LLM은 충분히 구현된다.
그야 Gemini에게 이제껏 없었던 우리들 개인의 노트북 안쪽 파일을 위의 수집 단계에서 가져오지 않았는가?
그러면 이제 Gemini는 우리가 가지고 있던 내 것을 공유하게 되었다. 얼마든지 그것을 활용해서 질문에 대한 답변을 돌려줄 수 있다.
하지만 생각해보자. 여러분이 LLM이 되었다고 상상해서, 이제 질문을 받아보는 것이다.
어느 날 잘 모르는 타 부서 상사가 갑자기 산더미 같은 서류를 내 책상 위에 쿵 올려놓더니, 갑자기 한 장으로 요약해서 정리해 라고 한다면?
여러분의 머릿속에는 ??? 라는 생각밖에 안 떠오를 것이다.
제가요? 아니 이게 뭔데요 일단 뭔지 설명이라도 좀 이라고 반문해 봤자, 회피할 수는 없다.
왜냐하면 여러분은 지금 회사에서 매달 월급을 받는 월간 구독형 LLM이기 때문이다. 상사의 요청을 받으면 수행해야 한다.
여러분의 부서장은 도와주지 않는다. 우리 부서의 사원이라면 당연히 해낼 거라며 싱글벙글 웃고 있다.
타 부서 상사는 말한다. 서류 다 갖다줬잖아. 제목도 있고, 내용도 있잖아. 똑똑하다고 들었는데, 설마 못 읽어? 라고.
그런데도 답을 하지 못한다면 구독을 끊겠지? 월간 구독형 LLM에게 있어서 그건 매우 곤란한 일이다.
결국 울면서 산더미 같은 서류를 한장 한장 뒤지며 비슷한 서류들끼리 분류하고 중복을 제거해서 압축하고 중요도가 낮은 서류는 제외하고, 그렇게 정리 요약을 조금씩 해 간다.
그러다 보면 당연하게도 누락이 생긴다. 스스로도 헷갈리기 시작하고, 말을 만들어내기 시작한다.
낯선 업무라서 서류만 보고는 뭔 소리인지도 모르겠는데 아무튼 보고서는 만들어야 하니까 어쩔 수 없는 일이다.
LLM의 환각 현상이 마구마구 발생하게 되는 순간이다.
여러분은 마감 시간에 맞춰 훌륭하게 답변을 돌려줄 수 있을 것이다. 우수한 LLM의 소양을 다시 한 번 증명했다.
단, 아마 그것은 잘게 잘게 뜯어보면 환각 현상이 심각한 답변일 테지만 말이다.
화려한 쇼맨쉽은 충분히 가능하겠지만, 실무적으로 쓸 수는 없는 것.
이 망상의 결론은 아래와 같다.
데이터를 그냥 가져다 주는 것만으로는 안 된다는 것이다.
그러면, 어떻게 해야 요약 보고서가 잘 만들어질 수 있었을까?를 되새겨보며 이 앞의 단계를 밟아보자.
문서 [ Document ] : 문서의 규격화
애초에 여러분, 즉 LLM은 초인이 아니다. 전지전능한 무언가가 아니니까 당연히 무리한 요구는 받아들일 수 없다.
여러분이 월 구독형 요금제에 따라 업무를 수행하는 만큼, 사실 그 요금에 따라서 발휘할 수 있는 성능은 정해져 있다.
까놓고 말해서 월급 3만원 받고 일하는데 매번 백만 장 문서 정리하라고 하면 퇴사한다.
즉, 타 부서 상사의 요청 자체가 사실 잘못되었던 것이다.
그럼 회고해 보자.
여러분은 위의 무리한 요구를 수행하면서 어떤 한탄을 하셨을까.
온갖 한탄이 하늘을 찔렀겠지만, 일단 비슷한 서류들끼리 분류하고 중복을 제거해서 압축하고 중요도가 낮은 서류는 제외하는 정도의 작업은 아 이 정도는 자기들이 해 놓고 요약을 부탁해야 맞는 거 아니야 라는 생각을 하셨지 않을까.
왜냐하면 짧은 시간 내에 정리 요약만 하는 것도 버거우니까.
분류, 압축, 제외 등 온갖 작업까지 다 해야 하는 삶이 개탄스럽기 그지없었을 것이다.
어느 정도 정리된 서류만 받았어도 내 보고서가 이렇게 허접하지는 않았다…… 같은 원념이 자라지 않았을까?
결국 거꾸로 보면, LLM에게 무슨 데이터를 던져도 일단 다 받아들이긴 하지만, 더 깔끔한 데이터를 줬을 때 그 성능이 잘 발휘될 수 있다는 결론이 된다.
Word, PPT, Excel, PDF 등 마음대로 만들어진 무수한 문서를 깔끔하게 정렬해서 제공한다면.
문서 타입을 구분하지 않고, 전부 제목 - 본문, 서론 - 본론 - 결론의 양식을 지켜준다면.
LLM은 훨씬 더 좋은 대답을 한다.
그렇기에, 이 영역에서는 문서들을 공통된 양식으로 통합하는 작업을 진행한다.
전처리 [ Refinery ] : 정리정돈, 분리수거
사실, 위에서 문서를 정리하다 보면 의아한 점이 생길지도 모른다.
바로 요약 보고서를 만드는 데 글씨체, 폰트 크기 같은 게 중요할까? 라는 의문.
물론 악랄한 타 부서 상사가 내가 3년 전 가을 바람이 불어오기 시작할 때 만든 기술 자료의 제목 폰트 사이즈가 뭐였지 생각이 안 나 생각이 안 나 같은 소리를 할 수도 있다.
하지만 그 확률이 굉장히 낮다는 것, 그리고 사실 별로 중요해 보이지도 않다는 것도 사실일 것이다.
즉 데이터의 우선순위가 매우 낮다.
그런 데이터는 여기서 제거해 버리면 된다.
문서의 규격과 내용 의미만을 보존한 채로 간략화를 하면 데이터도 가벼워지고 추후 필요한 데이터를 찾기도 빨라진다.
그리고 그를 위한 유명한 규격이 우리에게는 있다. 바로 Markdown이다.
간단한 문법으로 제목, 목록, 표 등의 문서 데이터가 가지는 기본 규격을 표현해 주는 이 규격으로, 우리는 문서들에서 우선순위가 낮은 데이터를 전부 쳐 내고 내용 의미만을 보존할 수 있다.
그런데 정말로 폰트 크기 같은 질문이 들어오면 어떡해?
그때는 한 단계를 거슬러 올라가, 위의 문서 영역에서 도출해 낸 결과를 뒤지면 된다.
이 전처리, Refinery 단계는 그저 이후 우리가 데이터를 좀 더 가볍게 지니고 읽기 쉽도록 하는 작업일 뿐, 원본을 파괴하는 게 아니니 말이다.
분할 [ Chunking ] : 처리할 수 있는 크기로
읽기 좋은 글에는 목차가 있고, 문단이 있고, 문장의 적절한 끝맺음이 있다.
물론 그 적절한 이 대체 구체적으로 어느 정도냐, 라고 한다면 너무나도 주관적인 영역이다. 그리고 그것이 이 분할, Chunking 작업의 난해함을 표현한다고 할 수 있겠다.
단, 1만 자를 마침표 없이 이어지는 문장은 누구라도 싫어할 것이라는 건 아무렴 명백하다.
언어 시험의 지문은 마침표가 있어도 일단 내용이 방대하면 읽기 버겁지 않은가? 촉박한 시간 속에 읽다보면 읽었던 것도 계속 까먹게 되지 않는가?
적당히 잘라줘야 편안하다는 것을 우리는 지난 학창 시절에 체득했을 것이다.
그러니까 우리는 데이터를 읽기 좋은 크기로 싹둑 싹둑 자른다.
그런데 여기서 새로운 문제가 또 불거지게 되는데……
적당히 감각적으로 깔끔한 크기로 잘랐다고 치자. 아주 좋다. 하지만 그 부분만 떼어놓고 보면 의미가 불명해져 버린다.
언어 시험에서 300자 정도의 지문을 제시하고 앞 내용과 뒤 내용을 맞춰보세요 라고 하는 것과 같다.
대개 이 경우에는 교과서의 사전 지식이 있거나, 객관식 보기로부터 유추가 가능하기는 하다.
하지만 교과서도 없고, 주관식이라면? 내가 어떻게 알아 가 되어 버린다.
하지만 세상이 답을 종용하니 결국 또 상상해서 답을 적을 수밖에 없고, 즉 환각 현상이 터진다.
결국 단순하게 자르는 것만으로는 부족하다.
읽기 좋은 크기로 잘라낸 뒤에 각 덩어리가 어떤 문서의 어떤 목차의 어떤 내용에서 발췌된 것인지, 고향에 대한 정보가 필요하다.
그것을 자그마한 코멘트로 달아두면, 아무래도 분석하는 입장에서는 이해가 한결 편안할 것이다.
포장 [ Wrapper ] : 잘라낸 조각들을 표준으로
여기서부터는 한 걸음 더 나아가 미래를 위한 밑준비다.
지금까지 원본 문서를 지지고 볶아서 한 입에 먹기 좋은 덩어리로 요리했다.
이제 포장을 할 때다. 지금 먹고 끝낼 거라면 굳이 포장하지 않아도 되지만, 두고두고 먹을 거라면 포장을 해 둬야 하는 법이다.
우리는 이전 단계에서 임의의 방식으로 적당히 감각적으로 데이터를 잘랐다. 그리고 그 방식은 이번에는 아주 잘 되었다.
하지만, 그 방식이 내일도 통할까? 운이 좋아 내일도 통했다고 치자. 언제까지 그 행운이 이어질까……
우리는 언제나 미래를 대비해야 한다.
당장 내일 또 다른 부서 상사가 자기 부서 전문 문서들을 잔뜩 들고 와서 어제 저쪽 문서 받았지 저쪽 부서장이랑 협의했는데 우리 거랑 합쳐서 요약해 주면 좋겠군 하하하…… 같은 요구를 할 수도 있다.
당연히, 이쪽 부서와 저쪽 부서는 다루는 분야도 다르고 업무 방식도 다르고 구성원도 다르다.
문서 양식도 근본적으로 다르다.
오늘 했던 적당히 감각적인 방식이 새로운 부서에는 통하지 않을 가능성이 매우 높다.
그렇다고, 양쪽 모두 서로 다른 적당히 감각적인 방식으로 데이터를 가공하면, 이제 두 데이터가 호환이 안 된다.
그렇다.
이 영역에서 그 호환이 가능한 밑준비를 해 두는 것이다.
우리는 모든 데이터를 우리만의 이 양식으로 정의하겠다, 라는 꽤 포괄적인 포장지를 준비해 두고 그 안에 욱여넣는 것이다.
그렇게 함으로서 서로 근본이 다른 데이터라 할지라도 소통이 가능하도록 하는 단계.
그 단계가 비로 여기 포장, Wrapper의 영역이다.
구축 [ Assembler ] : Knowledge Graph
이전 단계에서 데이터를 단순하게 자르는 것만으로는 부족하다고 이야기했다.
그렇기에 자르는 시점에 고향을 잊지 않도록 자그마한 코멘트를 달아두기를 권했다. 그리고 그 데이터는 포장의 단계를 거치면서도 오롯이 보존되었다.
이제 우리는 우리의 규칙 하에 같은 규격으로 포장된 많은 데이터 조각들을 가지고 있고, 각 조각들의 고향이 어디인지도 알고 있다.
하나 하나, 연결해 주도록 하자.
네비게이션에 목적지를 입력하면 어떤 경로를 타고 들어가야 가장 빠르게 도착할 수 있는지 그 최적화된 해답을 알려주는 것처럼, LLM에게 건네 줄 데이터 네비게이션을 여기서 만든다.
이제 우리는 지도를 보고 데이터를 찾아갈 수 있다.
저장 [ Loader ] : 작업 후 저장은 필수
마지막으로, 구축한 데이터 지도를 저장하자. 언제 어떻게 다시 필요하게 될지 모르니, 저장해 두는 게 좋다.
당장 내일 그 타 부서 상사가 내가…… 보고서를 받았던가……? 같은 말을 해도 그냥 금방 다시 만들어 제출할 수 있도록 말이다.
그래서 결론 : LLM이 일하기 편해짐
많은 단계를 거쳐 데이터를 해석하기 쉬운 형태로 구축해냈다.
이제 더 이상 비참하게 환각 현상을 만들어낼 필요가 없다. 유능한 LLM으로서의 성능을 뽐낼 수 있게 된 것이다.
LLM이 읽기 어려움 → LLM이 읽기 쉬움으로 데이터 가공을 한 사이클 마쳤다.
그럼 여기서 글을 마무리 짓고, 다음을 기약하자.
회사 블로그 게시글이니까, 마무리를 하는 이 즈음에서 다음 편 예고도 할 겸 회사 광고를 하겠다.
Sayou Fabric이라는 위에 나온 모든 단계별 기능이 종합된 오픈소스 라이브러리입니다!
GitHub Star Fork Watch 부탁드립니다!
GitHub : Sayou Fabric
pip install sayou-connector sayou-document ……
위 방식으로 설치해서 사용하실 수도 있습니다! 많이 사용해 주세요!
이번 편에 설명드린 데이터 준비 영역이다.
이제 비정기적으로 연재를 이어가며 계속해서 데이터 관점에서 바라보는 LLM을 말씀드릴 것이다.
우리들의 글을 읽어가는 분들이 AI를 쉽고 정교하게 다룰 수 있게 되기를 바라며, 글을 마친다.
긴 글 읽어주셔서 감사드립니다!